Closed Bug 1468870 Opened 7 years ago Closed 5 years ago

WhatsApp Web broken in Firefox all of a sudden, with "Firefox can’t establish a connection to the server at wss://w7.web.whatsapp.com/ws" (and I can't access that domain via HTTPS in Firefox either, but can in Chrome)

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1554218

People

(Reporter: dholbert, Unassigned)

Details

(Keywords: top100)

Attachments

(1 file)

http log
1.69 MB, application/octet-stream
Details
STR: 1. Visit https://web.whatsapp.com EXPECTED RESULTS: QR Code should be displayed. ACTUAL RESULTS: WhatsApp's throbber spins forever instead of QR Code. Additionally, I see this in Browser Console: =============== Content Security Policy: Directive ‘child-src’ has been deprecated. Please use directive ‘worker-src’ to control workers, or directive ‘frame-src’ to control frames respectively. Firefox can’t establish a connection to the server at wss://w7.web.whatsapp.com/ws. app.d84936ac910dd008587a.js:20:21586 Firefox can’t establish a connection to the server at wss://w8.web.whatsapp.com/ws. app.d84936ac910dd008587a.js:20:21586 =============== I'm using Ubuntu 18.04 -- I tested current Nightly and current release (60.0.2), using a fresh profile. Both give "Actual Results" (broken). Chrome gives me "Expected Results" on the same machine. NOTE: This was working as of a few days ago I think, so I suspect this regressed for us when WhatsApp changed something on their end.
https://www.alexa.com/siteinfo/whatsapp.com says whatsapp.com is #61 worldwide, #12 in Brazil.
Keywords: top100
I tried Firefox on Windows and Mac via browserstack.com, and I couldn't reproduce the issue there. (The QR code does load -- hooray! -- and I don't see any "Firefox can’t establish a connection to the server" errors in Browser Console). So there might be something Linux-specific here. (though again, I'm testing in a fresh browser profile & it does work in Chrome from the same desktop session)
I tried rebooting, and the issue persisted - still "Actual Results" (testing with a fresh browser profile). (But on Windows on the same machine, I get Expected Results.) (Not sure whether to blame an Ubuntu system package update, or a change on WhatsApp's end that happens to have linux-specific fallout, or what)
Additional data point: kamidphish gets "ACTUAL RESULTS" in Firefox within his Arch Linux environment.
It looks like Firefox on my linux environment is simply unable to connect to w7.web.whatsapp.com (and similarly dyn.web.whatsapp.com). E.g. these URLs trigger "Hmm. We’re having trouble finding that site.": https://dyn.web.whatsapp.com/ https://w7.web.whatsapp.com/ https://w8.web.whatsapp.com/ ...but load just fine in Chrome. So my working theory is that the local DNS server (on the Mozilla_All_Hands network) is horked (but in a way that only affects Firefox, and only for these web.whatsapp.com subdomains). Incidentally, if I enable DNS over HTTPS, then that fixes it for me! :D https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/
Component: DOM: Service Workers → Networking
Summary: WhatsApp Web broken in Firefox all of a sudden, with "Firefox can’t establish a connection to the server at wss://w7.web.whatsapp.com/ws" → WhatsApp Web broken in Firefox all of a sudden, with "Firefox can’t establish a connection to the server at wss://w7.web.whatsapp.com/ws" (and I can't access that domain has HTTPS in Firefox either, but can in Chrome)
Summary: WhatsApp Web broken in Firefox all of a sudden, with "Firefox can’t establish a connection to the server at wss://w7.web.whatsapp.com/ws" (and I can't access that domain has HTTPS in Firefox either, but can in Chrome) → WhatsApp Web broken in Firefox all of a sudden, with "Firefox can’t establish a connection to the server at wss://w7.web.whatsapp.com/ws" (and I can't access that domain via HTTPS in Firefox either, but can in Chrome)
FWIW, "curl" and "ping" both fail to resolve dyn.web.whatsapp.com in the same linux environment. So this isn't entirely linux-specific -- but Chrome somehow isn't affected by the problem.
This is WORKSFORME now (upstairs, on the Marriott_GUEST network). Given that ping & curl were both affected (and now work fine as well), I suspect this was a misconfiguration on the DNS server that I was connected to (and/or how linux interacted with it, since it was fine when I rebooted in windows). So, not a Firefox bug really. I'm still curious on why it worked in Chrome... I suspect Chrome was perhaps working around it by secretly using their own DNS server under the hood or as a fallback or something like that. *shrug*
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
I'm having the same problem. Firefox can’t establish a connection to the server at wss://w8.web.whatsapp.com/ws. app.12174fa72d7f41b3bf19.js:20:29397 Firefox can’t establish a connection to the server at wss://w1.web.whatsapp.com/ws. app.12174fa72d7f41b3bf19.js:20:29397 Firefox can’t establish a connection to the server at wss://w2.web.whatsapp.com/ws. app.12174fa72d7f41b3bf19.js:20:29397 Firefox can’t establish a connection to the server at wss://w3.web.whatsapp.com/ws. app.12174fa72d7f41b3bf19.js:20:29397 Firefox can’t establish a connection to the server at wss://w4.web.whatsapp.com/ws. app.12174fa72d7f41b3bf19.js:20:29397 Firefox can’t establish a connection to the server at wss://w5.web.whatsapp.com/ws. app.12174fa72d7f41b3bf19.js:20:29397 Screenshot: https://i.imgur.com/qdbAzYv.png
At the same time it works just fine in Chrome and Edge
Just here to give my "me too" as well with Nightly 64.0a1 (2018-10-01) on MacOS 10.13.6. Since this is still an ongoing issue, I'd like to re-open if there's any investigation that can be done (for the same reasons that dholbert mentioned in Comment 1).
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
For people affected by this: could you try running one of these commands from a terminal, and see if it succeeds? ping dyn.web.whatsapp.com ping w1.web.whatsapp.com ...or if you have 'curl' (e.g. perhaps on Mac): curl -vvv dyn.web.whatsapp.com curl -vvv w1.web.whatsapp.com See comment 6 -- when I encountered this, those tools were hitting the same sort of issue (though Chrome was not). It'd be helpful diagnostically to know if that's the case for other people, too.
QA Contact: jduell.mcbugs
QA Contact: jduell.mcbugs
(In reply to Daniel Holbert [:dholbert] from comment #11) > For people affected by this: could you try running one of these commands > from a terminal, and see if it succeeds? > ping dyn.web.whatsapp.com > ping w1.web.whatsapp.com > > ...or if you have 'curl' (e.g. perhaps on Mac): > curl -vvv dyn.web.whatsapp.com > curl -vvv w1.web.whatsapp.com > > See comment 6 -- when I encountered this, those tools were hitting the same > sort of issue (though Chrome was not). It'd be helpful diagnostically to > know if that's the case for other people, too. To make sure there's progress on this, I'll NI myself to follow up with the results.
Flags: needinfo?(jonalmeida942)
closing for lack of progress.
Status: REOPENED → RESOLVED
Closed: 7 years ago → 6 years ago
Resolution: --- → INCOMPLETE
Flags: needinfo?(jonalmeida942)

The issue is still there with Firefox 68.3 ESR and Firefox 72 beta. Setting network.http.spdy.websockets solves the problem.

Only happens when I configure Firefox with proxy.pac (in hour company all the PCs are configured like that)

(In reply to Dimas from comment #15)

Only happens when I configure Firefox with proxy.pac (in hour company all the PCs are configured like that)

Could you try to get the http log?
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

Thanks!

Status: RESOLVED → REOPENED
Flags: needinfo?(dimas.sc)
Resolution: INCOMPLETE → ---
Attached file http log —

Attached the http log

In the browser console I see:
El Firefox no ha pogut establir una connexió amb el servidor a wss://web.whatsapp.com/ws. app.fff9477f997fa1246faf.js:2:783554
(something like "Firefox was unable to establish a connection to the server wss://web.whatsapp.com/ws.")

Flags: needinfo?(dimas.sc)

From the log, I can only tell that there was something wrong about the authentication. The proxy server just returns HTTP/1.0 407 Proxy Authentication Required.

It seems you are using squid proxy locally. Could you try to figure out why the proxy authentication is failed?

Flags: needinfo?(dimas.sc)

Squid proxy log with...

Firefox / network.http.spdy.enabled.http2 true (default) / QR not loading

informatica5.trueta.intranet - - [09/Dec/2019:15:08:24 +0000] "CONNECT web.whatsapp.com:443 HTTP/1.1" 407 3755 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0" TCP_DENIED:NONE
informatica5.trueta.intranet - - [09/Dec/2019:15:08:24 +0000] "CONNECT web.whatsapp.com:443 HTTP/1.1" 407 4058 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0" TCP_DENIED:NONE
informatica5.trueta.intranet - 40447118p [09/Dec/2019:15:08:24 +0000] "CONNECT web.whatsapp.com:443 HTTP/1.1" 200 481 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0" TCP_MISS:DIRECT
informatica5.trueta.intranet - - [09/Dec/2019:15:08:24 +0000] "CONNECT web.whatsapp.com:443 HTTP/1.1" 407 4391 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0" TCP_DENIED:NONE

Firefox / network.http.spdy.enabled.http2 false / QR loading

informatica5.trueta.intranet - 40447118p [09/Dec/2019:15:16:29 +0000] "CONNECT web.whatsapp.com:443 HTTP/1.1" 200 818 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0" TCP_MISS:DIRECT
informatica5.trueta.intranet - - [09/Dec/2019:15:16:29 +0000] "CONNECT web.whatsapp.com:443 HTTP/1.1" 407 3755 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0" TCP_DENIED:NONE

Chrome / QR loading

informatica5.trueta.intranet - - [09/Dec/2019:15:09:45 +0000] "CONNECT web.whatsapp.com:443 HTTP/1.1" 407 3764 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36" TCP_DENIED:NONE
informatica5.trueta.intranet - - [09/Dec/2019:15:09:45 +0000] "CONNECT web.whatsapp.com:443 HTTP/1.1" 407 3764 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36" TCP_DENIED:NONE
informatica5.trueta.intranet - - [09/Dec/2019:15:09:45 +0000] "CONNECT web.whatsapp.com:443 HTTP/1.1" 407 4067 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36" TCP_DENIED:NONE
informatica5.trueta.intranet - - [09/Dec/2019:15:09:46 +0000] "CONNECT web.whatsapp.com:443 HTTP/1.1" 407 3764 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36" TCP_DENIED:NONE
informatica5.trueta.intranet - - [09/Dec/2019:15:09:46 +0000] "CONNECT web.whatsapp.com:443 HTTP/1.1" 407 4067 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36" TCP_DENIED:NONE
Flags: needinfo?(dimas.sc)

Note that to make it work, setting any of these two options to false is enough:

network.http.spdy.websockets
network.http.spdy.enabled.http2

Michal, could you take a look at this bug?
Thanks.

Flags: needinfo?(michal.novotny)

I probably cannot get to this bug soon. I did a quick test and I cannot reproduce it, but I've set proxy manually and my proxy uses basic authentication. Could you please check whether both proxy auto-configuration as well as ntml are needed to reproduce the issue?

Flags: needinfo?(michal.novotny) → needinfo?(dimas.sc)

(In reply to Michal Novotny [:michal] from comment #22)

Could you please check whether both proxy auto-configuration as well as ntml are needed to reproduce the issue?

I don't know if I understand what you're asking for. To do the tests I have selected the option "Automatic proxy configuration URL" pointing to the URL of the proxy.pac.

If I test with the option "Use system proxy settings" and in Windows we have the proxy configured the problem persists.
If I test with the option "Auto-detect proxy settings for this network" Firefox connects directly to Internet, without proxy.

Yes, our Squid proxy is configured with ntlm authentication. I don't have any test server to set up another proxy configuration without ntlm.

Squid ntlm configuration:

auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 30
#Pantalla emergent de navegador demanant usuari per loginar-se
auth_param basic program /usr/lib/squid3/squid_ldap_auth -v 3 -b "dc=htrueta,dc=intranet" -f uid=%s ra.trueta.intranet
auth_param basic children 5
auth_param basic realm Web-Proxy
auth_param basic credentialsttl 2 hours
Flags: needinfo?(dimas.sc)

(In reply to Dimas from comment #23)

I don't know if I understand what you're asking for. To do the tests I have selected the option "Automatic proxy configuration URL" pointing to the URL of the proxy.pac.

If I test with the option "Use system proxy settings" and in Windows we have the proxy configured the problem persists.
If I test with the option "Auto-detect proxy settings for this network" Firefox connects directly to Internet, without proxy.

I meant to use the same proxy that is resolved by proxy.pac, but set it manually. I.e. use "Manual proxy configuration" and set "HTTP Proxy" and "SSL Proxy" to point to your squid.

Yes, sorry, the same result configuring the proxy manually:


(screenshot https://i.imgur.com/c9co29H.png )

(In reply to Dimas from comment #26)

(screenshot https://i.imgur.com/c9co29H.png )

Please, don't use "Use this proxy server for all protocols" checkbox. See bugs 1601871 and 1577862 for details. Set just HTTP and SSL proxy.

Ok, tested setting only HTTP and SSL but the problem persist :-(

network.proxy.type;1
network.proxy.http;apis.trueta.intranet
network.proxy.http_port;8080
network.proxy.ssl;apis.trueta.intranet
network.proxy.ssl_port;8080

I tried https://www.websocket.org/echo.html and it seems to work

Thanks, so it seems the triggering combination is WS over HTTP/2 + NTLM.

Honza, given that NTLM is involved, could you please have a look?

Flags: needinfo?(honzab.moz)

If that's so, this seems to be a duplicate of bug 1554218.

Status: REOPENED → RESOLVED
Closed: 6 years ago → 5 years ago
Flags: needinfo?(honzab.moz)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: